Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SRS caching #1197

Merged
merged 19 commits into from
Oct 31, 2023
Merged

SRS caching #1197

merged 19 commits into from
Oct 31, 2023

Conversation

mitschabaude
Copy link
Member

@mitschabaude mitschabaude commented Oct 25, 2023

Cache SRS and Lagrange basis

closes #1119
bindings: o1-labs/o1js-bindings#192
proof-systems: o1-labs/proof-systems#1300

Details. This is a follow-up to #1187, which expands caching to include the SRS and Lagrange bases. Most of the lift is in the bindings PR, which refactors basis creation to happen in TS, and try to read from a user-defined cache first. The cache is put in a global variable at the start of compile() and unset at the end. This completely bypasses the Pickles caching logic, to avoid yet more refactors of the Pickles API.

In contrast to prover and verifier keys, SRS and Lagrange bases are very stable and won't need to be regenerated often. The SRS is a fixed list of curve points and exists once for both Pasta curves. So it will be generated once and not change after that. Lagrange bases have to be created once for every circuit size. The circuit size is a power of two and at most equal to the SRS size. In the typical case, a user will already have compiled a circuit of the same power of two, and will be able to read the Lagrange basis from cache.

In addition to enabling caching, the bindings PR uses a faster (multi-threaded) version of SRS creation. This brings a major speedup even on the first run, when the SRS isn't cached yet.

Results. Compiling the simple_zkapp.ts example becomes faster in various scenarios

  • Before Cache prover keys #1187 and this PR:
    • Every time: 20.8s
  • On this PR:
    • On the very first run (nothing cached): 13.7s / -34%
    • Bases cached, circuits changed: 12.7s / -39%
    • Everything cached: 2.93s / -86%

Note: Loading bases from cache is only 1s faster than regenerating them. The bottleneck is not reading the file, but conversion from the stored JSON format into the format needed by Rust. This should be easy to make faster and will be addressed in a future PR.

Cache directory now looks like this:
image

@mitschabaude mitschabaude changed the base branch from main to feature/pickles-js-caching October 25, 2023 11:44
@mitschabaude mitschabaude marked this pull request as ready for review October 31, 2023 08:31
@mitschabaude
Copy link
Member Author

mitschabaude commented Oct 31, 2023

Damn, it fails in the web version, I forgot to consider the weird worker-calling layer we have there 😞 Might need to refactor this a bit to work

EDIT: it was just updating the "wasm spec"

Base automatically changed from feature/pickles-js-caching to main October 31, 2023 13:33
@mitschabaude mitschabaude merged commit 9da5972 into main Oct 31, 2023
10 checks passed
@mitschabaude mitschabaude deleted the feature/parallel-srs-create branch October 31, 2023 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Avoid to recompute SRS
2 participants